Beacons are small, low cost, usually battery-operated, wireless devices emitting advertisement broadcast frames e.g. using Bluetooth Low Energy (BLE) protocol. The advertisement messages of the beacon devices can be received by a mobile device, such as a smartphone or a tablet, or other device that supports the specified protocol. Today, there are few different beacon protocols defined, such as iBeacon, UriBeacon, and Eddystone for example. All of them use the BLE advertisements to broadcast data and the beacon protocols specify the payload in the BLE advertisements.
FIG. 1 presents an example of beacon device operation. A beacon device 103 broadcasts BLE advertisements 106 periodically in one or multiple frequency channels. Mobile devices can attempt to receive the advertisements by scanning 105. In order to be able to receive the advertisements, a mobile device 102 needs to be inside the beacon device's radio range 104. A mobile device 101 outside of the radio range of the beacon device, cannot receive the advertisements.
Beacon devices have many different applications. Usually, in the envisioned applications, beacon devices are widely deployed in large quantities. Beacon devices have applications e.g. in retail, events, and transportation. In retail, beacon devices can be used e.g. for advertising, providing product information, and for contactless payment. In events, beacon devices can be used e.g. for communicating information and complementary content, and to promote sales. In transportation, beacon devices can be used e.g. for alerting travelers of delays and schedule changes, and reporting weather conditions.
Whilst there are multitude of envisioned applications for the beacon devices, there is no efficient way of connecting multiple beacon devices to an application system e.g. for management, status monitoring, and configuration purposes. To manage the beacon devices, there are currently three options: 1) configuration with a mobile device, 2) using end users' mobile devices as a gateway to an application system, or 3) adding extra gateway devices to enable connection between the beacon devices and an application system.
FIG. 2 presents an example of configuring a beacon device with a mobile device. When configuring with a mobile device 201, e.g. a smartphone, the user has to form a bi-directional connected BLE link 203 between the beacon device 202 and the mobile device 201. This means that the user has to be inside the radio range 204 of the beacon device. After the link 203 has been established, configuration can be done using an application in the mobile device 201. Usually the radio ranges of the beacon devices are in the scale of tens of meters. Thus, configuring large beacon installations requires lot of manual labor and increases maintenance cost of the system. In this scenario, remote management is not a possibility.
Another way of exploiting mobile devices is to use them as a gateway to an application system. The rationale in this method is that when the system is used, there are always end users' mobile devices nearby and they have connection both to the beacon devices and to an application system. However, this connectivity is intermittent and not guaranteed. There may be users in vicinity of some beacon devices at a specific time instant or then there may be not. The operator of the fleet of beacon devices cannot rely on this, as the infrastructure is it out of the operator's control. Also, in this scenario, the end user's data connection needs to be used for communication to the application system, which may be unacceptable for many end users.
FIG. 3 presents an example of connecting a beacon device to an application system using a mobile device. A mobile device 301 has to be inside the radio range 304 of the beacon device 302 to form a connection. In order to provide communication to and from the beacon device 302, a bidirectional BLE link 303 has to be established between the mobile device 301 and the beacon device 302. The mobile device includes a backhaul connection 305 e.g. via cellular or Wi-Fi. A connection between an application system 306 and the beacon device 302 can be established by running software in the mobile device 301 that relays data between the two entities. This connection can be used for e.g. remotely configuring the beacon device 302.
By adding extra hardware acting as gateway between the beacon devices and an application system brings application system connectivity control to the operator and gives possibility for remotely managing the beacon devices. However, as BLE is a star topology, the amount of extra hardware needed (the gateways) scales up with the amount of beacon devices installed and with the geographical coverage of the beacon device installation. This increases the system cost significantly, especially in large installations.
FIG. 4 presents an example of connecting a beacon device to an application system using an additional gateway device. A gateway device 401 has to be inside the radio range 404 of the beacon device 402 to form a connection. In order to provide communication to and from the beacon device 402, a bidirectional BLE link 403 has to be established between the gateway device 401 and the beacon device 402. The gateway device includes a backhaul connection 405 e.g. via cellular, Wi-Fi, or Ethernet. A connection between the application system 406 and the beacon device 402 can be established by running software in the gateway device 401 that relays data between the two entities. This connection can be used for e.g. remotely configuring the beacon device 402. The gateway device 401 has to include interfaces for both the backhaul connection 405 and BLE connection 403.
FIG. 5a illustrates an example of a beacon device hardware architecture. A beacon device 500 includes a memory 501, microcontroller unit (MCU) 502, a radio transceiver 503, antenna 504, and a power supply 505. The MCU 502 is used to run program code for a possible application and the BLE advertisement protocol. The radio transceiver 503 is used to transmit the BLE advertisements via the antenna 504. The power supply 505 includes components for powering the device, such a battery and a regulator.
FIG. 5b presents an example of a gateway device hardware architecture. A gateway device 550 includes a memory 551, microcontroller unit (MCU) 552, a radio transceiver 553, antenna 554, backhaul connectivity 555, and a power supply 556. The MCU 552 is used to run program code for a gateway application and BLE connectivity protocol. The radio transceiver 553 and antenna 554 are used form bidirectional BLE links to beacon devices inside gateway device's radio range. The backhaul connectivity 555 is used to form bi-directional connection to the application system. The gateway application relays data between the application system and a beacon device using the backhaul connectivity and BLE connectivity. The power supply 555 includes components for powering the device. The gateway device may also implement the beacon advertisement functionality.
Wireless Mesh Network (WMN) is a general term for types of networks where devices can communicate with each other not only directly, but also indirectly over multiple hops using other nodes in the network for routing data between communicating endpoints. Other general terms also used on this types of networks include ad hoc networks, Wireless Sensor Networks (WSN), Wireless Sensor and Actuator Networks (WSAN), Low power and Lossy Networks (LLN). A WMN usually constitutes of multiple nodes devices, and one or multiple gateway devices. The gateway devices provide connection between the WMN and other networks, such as Internet. WMNs are characterized to be autonomous and low power. Usually, WMNs employ either a time-slotted or a contention-based channel access method at the link layer.
FIG. 6 presents an example of time-slotted WMN link layer operation. The communicating nodes 601, 602, 603 use time slots 604 for exchanging data 606. The time slots are synchronized using a WMN protocol-specific signaling method. Time outside the synchronized time slots is inactive time 605 and e.g. the radio transceiver is not used. This time can be used e.g. to conserve energy by going to deep sleep mode resulting in low power operation.
FIG. 7 illustrates an example of contention-based WMN link layer operation. For the devices that can route data 701, 702, the radio is active all the time 704 resulting in increased power consumption. If there is nothing to send the radio is kept in reception mode. This way, when another device has data to send, it can do it immediately 705. The specific method for accessing the channel is WMN protocol-specific and e.g. CSMA-CA or Aloha can be used. There may also be sleepy end nodes 703 that cannot route data, and can be inactive if nothing to send.